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This paper describes the technological development of Fujitsu Habitat, and outlines its 
structure and features. Fujitsu Habitat is a new type of personal computer communication 
system that supports multimedia processing. It synchronously generates pictures, sounds, 
and characters — a feat which cannot be performed by conventional personal computer 
communication systems. 

This system is operated by linking Fujitsu's FM TOWNS hypermedia personal computer to 
a UNIX host machine. 

Communication between the host and terminals is done using a unique communication 
protocol that ensures high-efficiency and high-reliability data transmission. 


1- Introduction 

The FM TOWNS hypermedia personal com¬ 
puter has been on the market since February 
28, 1989. The standard model comes with a 
540-Mbyte CD-ROM drive and powerful audio¬ 
visual functions to facilitate hypermedia proc¬ 
essing. 

This paper describes Fujitsu Habitat, which 
is a network based multi-player game utilizing 
the hypermedia capabilities of the FM TOWNS. 
Fujitsu Habitat creates an imaginary world in 
a network host computer. People having access 
to an FM TOWNS can live in that world and 
interact with other users. 

Each user is given a body and an inter¬ 
changeable head. Users can talk with each other 
and move around in a virtual world-animation. 
Fujitsu Habitat is an interesting and very enjoy¬ 
able audio-visual multiplayer game. The present 
population of Fujitsu Habitat is about 2 000 
and is expanding. 

Currently, this service is offered as a per¬ 
sonal computer communication service of 
“NIFTY-Serve” by N.I.F. Corp. (a joint corpo¬ 


ration of Fujitsu and NISSHO IWAI Corp.). 

Although Fujitsu Habitat is just a game at 
this stage, some people have formed companies 
in that world, and are even doing business. This 
shows how a hypermedia network society can 
evolve, and how it may become useful. It is 
a challenging experiment and we are very inter¬ 
ested in seeing how it develops. 

Habitat was originally developed by 
LUCASFILM Ltd. 1} in the U.S. 

Fujitsu licensed it from LUCASFILM Ltd. 
and then modified it into Fujitsu Habitat. 

We have modified all the pictures (e.g. heads, 
bodies, scenery, and buildings) and audio data 
to suit Japanese users. 

The functional distribution between the 
network host computer and the FMTOWNS 2) 
has been redefined to fully utilize the hyper¬ 
media capabilities of the FM TOWNS. All the 
data for pictures and sounds is contained in a 
CD-ROM loaded in all participating FM TOWNS 
computers. Communication is very efficient 
because the only information that needs to be 
sent is information required to select pictures 


Fujitsu Habitat is based on LUCASFILM technology. The UNIX operating system was developed by and is licensed by AT&T. 
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Table 1. Basic commands 


Command 

Functions 

GET 

Get object 

PUT 

Place object 

DO 

Take action 

(e.g. sit on chair, open/close door) 

GO 

Walk 

HLP 

Get help message 

WSP 

Wisper to specified person 


Table 2. Function commands 


No. 

Functions 

1 

Change Avatar 

2 

Change sound or music 

3 

Raise right hand 

4 

Raise both hands 

5 

Punch 

6 

Jump 

7 

Change direction 

8 

Go back to menu screen and terminate 
Fujitsu Habitat 


and sounds. This avoids the need to transmit 
bulky multimedia data. The communication 
protocol has also been improved to achieve 
higher transmission efficiency and reliability. 

2. Outline of Fujitsu Habitat and its system 

Fujitsu Habitat is an imaginary visual world 
created in a network. It consists of zones, some 
examples of which are the residential zone, 
downtown zone, park zone, forest zone, and 
dungeon zone. Each zone consists of more than 
ten interconnected regions. A region equals one 
screen display. For example, the downtown 
zone consists of a cafe, a bar, and toyshop. 
There are about four hundred scenes in total. 

When a user subscribes to this system, he 
or she must first select a body and a head (avail¬ 
able at the head shop) to form a character re¬ 
ferred to as the user’s Avatar. (An Avatar is the 
combination of a body and one of more than 
1 000 ready made male, female, old, young, ani¬ 
mal and monster heads.) The user can then start 
his and her life in Fujitsu Habitat through an 
Avatar from a condominium in the residential 
zone. Money to live on is given when the user 



Fig. 1 —Terminal screen (scene in a condominium). 

subscribes. Users manipulate their Avatars by 
giving commands using a mouse. For instance, 
if a user gives a GO command while pointing to 
a place on the ground, his or her Avatar will 
walk to that place. If it is given a command to 
go to the edge of the screen, it moves to the 
adjacent area. If it is given a GET command 
for an object on the ground, it will pick it up. 
These basic commands are shown in Table 1. 
Table 2 shows function commands for other 
movements such as raising hands, changing 
direction, and punching. 

When users meet other Avatar in the screen 
world, they can talk to the users of those 
Avatars through the keyboard (see Fig. 1). 

In this imaginary world, an Avatar can go 
shopping with money and chat with friends. 
Many users can have simultaneous access to the 
same screen and thereby have an interactive 
experience in another world. 

Figure 2 shows the network configuration 
of Fujitsu Habitat. It consists of the FENICS 
network (Fujitsu digital network) and public 
lines. 

Fujitsu Habitat can be accessed at the 
standard national charges by connecting an 
FM TOWNS (hereinafter called a terminal) to 
an access point. The host center consists of the 
Fujitsu Habitat Center and the NIFTY-Serve 
Center. 

Access to Fujitsu Habitat requires an ID card 
subscription to NIFTY-Serve. The NIFTY-Serve 
Center is responsible for password control and 
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FENICS network Fujitsu Habitat Center 



Fig. 2-Configuration of Fujitsu Habitat network. 


Table 3. Service requirements of Fujitsu Habitat 


Item 

Improvement 

Realtime 

processing 

Use a process to share data between 
host and terminals that minimizes 
communication traffic. 

Terminal 

operability 

Make Fujitsu Habitat easy to use. 

Expansibility 

Use a program structure that allows 
the Fujitsu Habitat Center to be 
expanded into a multi-host system 
in anticipation of large increase in 
the number of users. 

Distribute processing between host and 
terminals to minimize software 
modifications even when the func¬ 
tions are extended. 

High 

reliability 

Localize troubleshooting and 
automated task recovery processing. 
Use a communication protocol suited 
to public communication networks. 


accounting. To meet these service requirements, 
improvements have been made to realtime 
performance, terminal operability, expansibility, 
and reliability. These improvement are outlined 
in Table 3 and are discussed in the next chapter. 

3. System configuration 

3.1 Concept of function distribution between 
host system and terminals 
The functions of Fujitsu Habitat are dis¬ 
tributed between the host system and terminals. 
A very important aspect of designing a distrib¬ 
uted processing system is how to assign the func¬ 
tions between the host and terminals. The re¬ 
sponse time is greatly affected by this assignment. 


When transmitting visual data, it is usually 
important to minimize the amount of data to 
be sent. In the case of Fujitsu Habitat, direct 
transmission of visual data would involve more 
than 10-Kbyte per transaction. This would 
not be practical from the viewpoint of response 
time. To solve this problem, the image data 
of Fujitsu Habitat is stored in the terminal’s 
CD-ROM. The parts of control information 
are controlled by the Fujitsu Habitat Center. 
Images are retrieved from the CD-ROM accord¬ 
ing to commands from the Fujitsu Habitat Center. 

The same processing method is also used 
for musical tones and audio effects. 

By adopting this method, this system has 
a response time short enough for a realtime 
system. This method gives the flexibility 
required to immediately act on the control 
information sent from the Fujitsu Habitat 
Center in response to events occuring in Fujitsu 
Habitat. 

The host program controls object informa¬ 
tion indicating the following: whether an 
object (e.g. a tree, building, or head) can be 
picked up or carried, how various objects can 
interact with each other, Fujitsu Habitat’s 
world map information, and Avatar information 
(indicating user IDs, and the assets and positions 
of Avatars). It also issues commands to the 
terminals. 

The terminal program processes animation 
(e.g. walking, jumping, and hand raising) and 
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generates audio effects (e.g. a bang when a door 
is closed) according to commands from the 
Fujitsu Habitat Center. 

To improve the efficiency and reliability 
of data transmission between the terminal 
program and host program, a unique com¬ 
munication protocol called the Fujitsu Habitat- 
link protocol (hereinafter called H-Link) was 
developed (see section 3.4). 

We will now outline the total system process¬ 
ing flow for the function distribution mentioned 
above. 

The Fujitsu Habitat system consists of three 
major phases: the log-in phase, service phase, 
and log-out phase. 

In the log-in phase the host transfers the user 
ID and password transmitted from the terminals 
to the NIFTY-Serve Center. It then receives 
the sendback information from the NIFTY- 
Serve Center after checking it against the user 
control information kept there. The host then 
issues a request for the accounting information. 
While this is happening, the terminal displays 
a Fujitsu Habitat picture (see Fig. 1) and waits 
for the user’s input. When it receives the input 
the terminal changes to the service phase. 

In the service phase, the terminal processes 
instructions from the mouse and conversation 
text input from the keyboard. It then post the 
actions and associated coordinates to the Fujitsu 
Habitat Center as an internal command. The 
host then does the following: analyses the trans¬ 
ferred internal command, determines whether 
the command can be carried out, determines 
the consequences of the action (if executable), 
and finally transfers the results (i.e. the changes 
to be made to the animation) as an internal 
command. The terminal then processes the 
animation and waits for the next input from 
the user. 

In the log-out phase, the user issues the 
log-out instruction; then the terminal posts 
it to the Fujitsu Habitat Center and disconnects 
the line. The host updates the user control 
information to the latest user status and informs 
the NIFTY-Serve Center that the accounting 
information has been obtained. 



■<D- 



Destination 



-CD- 


Fig. 4—Avatar movement route (top view). 


3.2 Screen control 

The screen control function enables display 
of a smoothly animated three-dimensional 
world. This function achieves this by mapping 
and by separating objects into parts. The attrac¬ 
tiveness and realism of the Fujitsu Habitat 
display owes much to this function. 

The map is an area in the host which 
indicates how an object is to be displayed 
and positioned in a region. As shown in Fig. 3, 
it is a three dimensional expression with X being 
the length, Y the height, and Z the depth. 
Objects in the screen background are positioned 
in the deepest plane. Movable objects and 
Abatars are positioned in other planes. The 
terminal draws the screen in stages from the 
back plane to the front plane. This process 
superposes near objects over far objects. The 
map is also used to identify objects pointed 
out by the mouse. 

When a user issues the GET comman; 
for an object on the screen, the terminal ser.c> 
the object’s X, Y coordinates and the comman; 
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type. (The terminal has no concept of depth and 
does not handle Z-coordinate data.) The host 
program then checks whether objects found in 
the Z planes at the X, Y positions are portable. 
(The planes are checked starting with the front 
plane). 

For a GO command, the host program 
checks whether the specified position is already 
occupied. Route checks are made in two ways to 
determine whether a specified route is clear 
(see Fig. 4). When a movement is completed, 
other Avatars in the scene are reoriented so 
that they all face the screen. This reorientation 
is made in preparation for the next move 
instruction from the mouse. 

The FM TOWNS has a powerful sprite func¬ 
tion, and the terminal program makes full use 
of it to display animations. To give depth 
to the scene, display priority is given to objects 
at the front. The nearer an object is to the 
back plane, the lower its display priority. Object 
image data is divided into small segments to 
enable smooth animation of a variety of move¬ 
ments. For example, an Avatar consists of 
fourteen segments, each of which is further 
divided into four patterns corresponding to 
views from the front, rear, right, and left. 
Further more, each pattern can be viewed 
from sixteen different angles (see Fig. 5). 

When making an animation, the terminal 
draws the parts according to commands from 
the host. When an Avatar walks or raises its 
hand, all necessary control information specify¬ 
ing the parts to be moved for each phase and 
the delays between displays is simultaneously 
managed. The commands that must be 
simultaneously executed are collectively referred 
to as cell data. The terminal program begins 
an animation by referencing this data. The 
selection and display order of cell data can be 
changed by a command from the host. An 
action such as “face forwards and walk back¬ 
wards” is processed by modifying the host 
program. 

3.3 System control 

This section introduces the concept of 
multi-host distributed processing, file control, 
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Fig. 5—Object parts. 

and impediment control of the host computer 
system. 

In anticipation of future increases in the 
number of users and communication paths, 
the Fujitsu Habitat Center was built as a multi¬ 
host structure using the LAN system to balance 
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the load between host computers. The process¬ 
ing is distributed as shown in Table 4. 

For inter-task communication using a multi¬ 
host configuration, it is usually necessary 
for the inter-task communicators to decide 
which host should have the other task. Further¬ 
more, because LAN communication of this 
system is made at the inter-host communication 
section, an application program can be produced 
without concern for the physical configuration. 
Figure 6 illustrates this concept. 

The DB control section controls the Fujitsu 
Habitat data base. This data base is a collection 
of smaller data bases, for example, the user ID; 


Table 4. Distribution of processing 


Host type 

Major distributed functions 

FEP 

(Front End 
Processor) 

Communication control section 

User control section 

NIFTY-Serve control section 

Inter-task communication section 

LAN communication section 

BEP 

(Back End 
Processor) 

Region control section 

Data base access section 

Inter-task communication section 

LAN communication section 


user information data base for names; region 
data base for the region connection status; 
object data base for region manipulation for ob¬ 
jects; and the mail, bulletin board, and docu¬ 
ment data bases for the text of memos. This 
information is controlled using C-ISAM note) , and 
deadlocks are avoided by using a general exclu¬ 
sive control system. 

We will now describe the fault control 
method used in this system. 

During online operation, if an application 
task (consisting of a user control section and 
a region control section) fails to continue 
processing due to an abnormality (e.g. a process 
contradiction), the work can still be continued 
without online disconnection. This is achieved 
by activating the task recovery function, which 
recovers the failed task only (see Fig. 7). 

Task recovery processing is done in the 
following stages: return of stored data in the 
task, garbage collection such as enforced unlock- 

Note: C-ISAM is a registered U.S. trade mark of 
INFORMIX SOFTWARE Inc. 


LAN 



Fig. 6—Concept of inter-task communication. 
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Fig. 7—Concept of task recovery. 


ing of locked resources, collection of memory 
information required for failure analysis, output 
of a message giving the error cause, and program 
reloading. 

Task recovery processing does not perform 
control line tasks other than application tasks. 

For a multi-host configuration, system 
monitoring must be integrated to reduce the 
burden on the center operator and to enable 
the system controller to monitor the total 
system. In this system, a master/slave relation¬ 
ship is established between hosts, and work can 
be done through the master host. The master/ 
slave relationship is stored in the host definition 
file, so the starting program must first read the 
memory. The console terminal of the master 
host not only stores the system control inputs 
for start and termination of Fujitsu Habitat, 
but also displays messages received from each 
rrogram. The slave host accepts non-interference 
commands, for example, running status indica¬ 
tion commands (see Fig. 8). 

3 4 H-Link protocol 

This section describes the concept and char¬ 


acteristics of the H-Link communication proto¬ 
col. used between Fujitsu Habitat and terminals. 

3.4.1 Background 

Fujitsu Habitat was designed to transfer 
pictures, music, and sound effects between 
the host and terminals with the minimum 
of data transmission. 

Another design target was low-cost yet high- 
reliability data transmission. Because data 
exchanged between the host and terminals is 
not image information but control information, 
data transmission errors might severely disrupt 
the service. 

Fujitsu Habitat can be accessed via public 
communication networks using general purpose 
hardware for personal computer communica¬ 
tions. 

Personal computer communication is usually 
performed using communication protocols, for 
example, asynchronous procedures and 
XMODEM (see Table 5), or using special hard¬ 
ware such as an MNP note) modem. Both these 
methods have advantages and disadvantages 


Note: MNP is a registered trade mark of Microcom Inc. 
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FEP LAN BEP 



Fig. 8—Centralized supervision at Fujitsu Habitat Center. 


SOP 

TYPE 

WN 

(S) 

WN 

(R) 

N 

(S) 

N 

(R) 

CONT 

TEXT 

CRC 

EOP 

1 

1 

1 

1 

1 

1 

1 

0-2 038 

2 

1 


._ (bytes) 

_J : Data requiring transmission processing 


Fig. 9—H-Link protocol data format. 


Table 5. Comparison of communication protocols 


Communica¬ 
tion protocol 

Effi¬ 

ciency 

Reli¬ 

ability 

Cost 

General evaluation 

Asynchronous 

procedures 

Low 

Low 

Low 

Low efficiency 
and reliability 

XMODEM 

Low 

Medium 

Low 

Low efficiency 
due to confir¬ 
mation of ACK / 
NAC transmis¬ 
sion per packet 

MNP 

mounted 

modem 

High 

High 

High 

Too expensive 
due to adjust¬ 
ments required 
for user’s hard¬ 
ware 


regarding efficiency, reliability, and running 
costs. 

To satisfy the design goals of efficiency, 
reliability, and economy for Fujitsu Habitat, 


we developed the H-Link communication 
protocol. 

3.4.3 Data format of H-Link protocol and 
its characteristics 

Figure 9 illustrates the data format of 
H-Link protocol. 

Conversational messages, image control, 
and other information is transferred between 
host and terminal in this format. One informa¬ 
tion packet includes control information and 
transmission data having a variable word length. 
The maximum amount of data in one packet 
is 2 048 bytes. Each packet starts with SOP 
(Start Of Packet) and ends with EOP (End Of 
Packet). The type section of each packet 
indicates the type of information it contains (see 
Table 6). 

If a message is too large for one packet, the 
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Table 6. Functions of TYPE section 


TYPE 

Information type 

Function 

T 

Data 

(information) 

Used for normal data 

r 

Data (polling) 

When the number of 
windows reaches a 
specified value 

“R” 

Response request 
(request) 

Confirmation request 

“A” 

Status report 
(ACK) 

Normal status response 


Resend request 
(NAK) 

Packet resend request 


Table 7. Types and functions of CONT section 


CONT 

Information type 

Function 

“O" 

ONLY 

Indicates packet contains 
entire message 

T 

FIRST 

Indicates packet contains 
first part of a multi¬ 
packet message 

“M” 

MIDDLE 

Indicates packet contains 
middle part of a multi¬ 
packet message 


LAST 

Indicates packet contains 
last part of a multi¬ 
packet message 


Table 8. Features of H-Link protocol 


Targets 

Characteristics 

High transmission 
efficiency 

Data can be transmitted and 
received as binary data. 

Window control enables continu¬ 
ous sending of packets. 

Capable of full duplex 
communication. 

High reliability 

CRC error detection. 

Confirmation of lost packets and 
overlaps using a sequence number. 

Non-response detection using time 
monitoring. 

Monitoring of non-communication 
and assessment of line quality at 
a rated distance. 


remainder is transmitted using additional 
rickets. For multi-packet messages, reception 
confirmation for each packet would lower 
:he transmission efficiency. To overcome this 
rror'.em. the required number of packets 
numbers) is determined by the host 
ir.c tenninal. and confirmation is made when 
il rickets have been transmitted. The window 


serial number (WN) checks for logical en:rs 
in the received transmission. The packet serii^ 
number (N) prevents a packet from being osz 
or overlapped with another packet. 

CONT (Continue) indicates whether a 
message continues in another packet, and is 
used by the receiver to assemble the packets. 
The types and functions of the CONT section 
are shown in Table 7. 

The text section contains a transmission 
message or object control data. Transparent 
processing of data is performed to enable the 
sending and receiving of binary data. 

The CRC section is the CRC value from 
SOP to TEXT. If a CRC error is detected, 
a retransmission request is made. 

The use of the H-Link message format 
ensures a high transmission reliability and 
efficiency. The characteristics of this format 
are summarized in Table 8. 

4. Conclusion 

This paper has focused on the key technolo¬ 
gies used in the Fujitsu Habitat system; it has 
also outlined the system configuration and 
programs. 

This system was developed as a personal 
visual communication system. By minimizing 
the volume of data to be transmitted, it achieves 
a higher response speed than conventional 
graphic communication systems. This minimiza¬ 
tion and subsequent high speed was made 
possible by Fujitsu’s large-capacity CD-ROM 
mounted personal computer FM TOWNS, 
and by the development of the H-Link protocol. 

This service was initiated on January 26, 
1990, and was initially provided free of charge. 
It was continued on a commercial basis starting 
from February 10, 1990. Within its first six 
months, more than 2 000 people ranging from 
eleven to sixty years of age had become users. 
All users, young and old, male and female, 
are enjoying themselves in Fujitsu Habitat. 
(Some enthusiastic members are reportedly 
spending more than 150h/month on the 
program.) This new type of system for com¬ 
munication by personal computer is now attract¬ 
ing considerable attention. 
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Fujitsu is now developing a “Gameland” 
and a “Business Land” to further entertain 
the inhabitants of Fujitsu Habitat and other 
customers. These developments are expected 
to be completed within a year. 
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